I hereby agree to the terms of the CLA available at: https://databend.rs/dev/policies/cla/

Summary

Background:

this pr is a sub aux task of database object sharing.

By keeping a hint file for each table, which contains the location of the table's last snapshot, the sharing service could work by accessing object storage only (without touching metastore service or databend-query nodes).

@ZhiHanZ @flaneur2020 please correct me if the above summary is not right.

some refs:

• the rfc https://github.com/datafuselabs/databend/blob/db576e71f3eb9b7c3021bcb0a6190ea4535e7146/docs/doc/60-contributing/03-rfcs/20220809-share.md
• Database sharing #3430
• Feature: tracing issue of share SQL support #6973

Functionality of this PR

whenever a table has successfully committed, try keeping a hint file that indicates the location of the last snapshot of given table:

• at "fixed" location
  /$STORAGE_PREFIX/$DB_ID/$TABLE_ID/last_snapshot_location_hint
• the content is a plain string, which describes the location of the latest snapshot
  /$STORAGE_PREFIX/$DB_ID/$TABLE_ID/xxxxx.json
  where
• STORAGE_PREFIX is configured by the parameter root of storage types

e.g. for local file system storage type, the hint looks like:

• path /tmp/.tmpNP66QH/1/11/last_snapshot_location_hint
• content of the above file /tmp/.tmpNP66QH/1/11/_ss/28a2109a67544c73a5af922acbabce68_v1.json

NOTE:

    Just try our best to write down the hint file of the last snapshot
     - will retry in the case of temporary io failure
    but
     - errors are ignored if writing is eventually failed
     - errors (if any) will not be propagated (just warning log messages left)
     - "data race" ignored
       if multiple different versions of hints are written concurrently,
       it is NOT guaranteed that the latest version will be kept

misc:

• refactor. unify table committing path

Fixes #issue